Curse

Targren · Oct 12, 2007, 07:21 AM // 07:21

Quote:

Originally Posted by holababe

Because otherwise it's an infringement of copyright.

No, what I mean is, if it prevents you from playing content you haven't paid for, what can you play, since the official content won't be available and I doubt the online store is going to start stocking codes for home-grown content...

Does it mean it's just a matter of the maps, keeping you from going to GWEN maps if you don't own the expansion, for instance? See what I'm saying?

holababe · Oct 12, 2007, 07:42 AM // 07:42

It would just be the same as offical GW.
If you don't have an authorized Factions key, then you cannot use Factions skills/content.

At least that's how I'd envisage it.

Explodie · Oct 12, 2007, 08:09 AM // 08:09

Maybe make a way that you have to login with your excisting login name, that Anet controls?
So you can handle fraude with players, but i hope that "Names" and "Passwords" wont be visible while playing?
So if there is a file called users.txt
Because alot of players use the same passwords for everything, and if a friend is hosting a private servers to "Cheat alot" he can people login and then steal the accounts >.>

Gusnana1412 · Oct 12, 2007, 02:24 PM // 14:24

Quote:

Originally Posted by Ajaala

Thank you for responding Gaile, I'd like to post a comment from the project lead for you and everyone else interested in the project.

Quote:

Originally Posted by GWLP Project Leader

GWLP is being developed with existing players in mind, as such we do not aim nor condone copying or emulating the Guild Wars plot, storyline, missions, quests, NPC layouts and so on. Instead we aim to allow users to develop their own quests, their own missions, their own Guild Wars themed sandbox. Our server will be in no way a replacement for the official server, even if players who did not own the official chapters were to play on it, they would not be playing Guild Wars or taking part in the Guild Wars experience.
That said, we plan to implement an authorization system that allows players access to only the content they have purchased. The authorization system will run in the background when you log into your official account, it will monitor incoming packets and read what you have access too on your account. It then encrypts this information and sends it to the server you wish to play on, the server immediately stores it in the database and allows you to use only the content that you own. The data that is gathered for authorizing a player can in no way be used to find that person's official account.

This project is being developed by and for Guild Wars fans, we hold both ArenaNet and Guild Wars in high regard and would hate to harm the community in any way. We believe our project to be only beneficial and not at all a substitute for playing on the live servers. We hope to maintain a good relationship with ArenaNet.

Reading data from other users data/connection or intercept data between User and GW should not that be Illegal action?

Note for ANet, by the so called "implement an authorization system" from GWLP Project, it shows that there will be a need to improve data encryption between GW Server and Client. Meaning that *collecting* other users data from third party is possible hence it should be fully encrypted informations and not visible for third party to intercept.

DarkNecrid · Oct 12, 2007, 02:49 PM // 14:49

its not illegal cause Anet said it isnt, k

Akaraxle · Oct 12, 2007, 02:50 PM // 14:50

Random comments/opinions:

The entire Guild Wars client (chapters + expansion) is publicly available and downloadable from the official website. What you're buying is the box, the manual, and the cd-key that allows you to play on their server. In short, you buy a lifetime license that allows you to make use of a service, rather than a software license.
To develop a server emulator, you must do one or both of the following: reverse engineering (debug/trace/dump), packet sniffing. This area is kinda shady, I don't know the legislation in the US but I think the former is not legal; not sure about the latter.
As ANet stated several times, Guild Wars runs most of its stuff server side and the client is no more than a dumb piece of software that shows the player what the server tells him to. I highly doubt the GWLP will ever replicate a full GW campaign, as that would be a humongous work these guys won't do. They'll have their hands more than full with trying to make skills work.

I certainly wrote something wrong somewhere, but as I stated these are mere assumptions.

Ajaala · Oct 12, 2007, 03:29 PM // 15:29

Quote:

Originally Posted by Gusnana1412

Reading data from other users data/connection or intercept data between User and GW should not that be Illegal action?

Note for ANet, by the so called "implement an authorization system" from GWLP Project, it shows that there will be a need to improve data encryption between GW Server and Client. Meaning that *collecting* other users data from third party is possible hence it should be fully encrypted informations and not visible for third party to intercept.

You do not understand our authorization system. It does not record your username and password at any time, all it does is wait for you to log into a real account and identify the packets that say "Ok! Ajaala owns chapter 2!" and so on, it then sends that information "Ajaala owns chapter 2" to the GWLP server, which lets you use chapter 2 content. At no point does it use your username, password, or any other personal information. The only info it looks at is what you own. There is no security risk and Anet does not need to modify their login system.

Quote:

Originally Posted by Akaraxle

[*]As ANet stated several times, Guild Wars runs most of its stuff server side and the client is no more than a dumb piece of software that shows the player what the server tells him to. I highly doubt the GWLP will ever replicate a full GW campaign, as that would be a humongous work these guys won't do. They'll have their hands more than full with trying to make skills work.[/list]

That is not our aim, more information in the original post and subsequent posts.

Quote:

Originally Posted by Explodie

Maybe make a way that you have to login with your excisting login name, that Anet controls?
So you can handle fraude with players, but i hope that "Names" and "Passwords" wont be visible while playing?
So if there is a file called users.txt
Because alot of players use the same passwords for everything, and if a friend is hosting a private servers to "Cheat alot" he can people login and then steal the accounts >.>

We do not need Anet's help to verify users own certain content, nor will anyone's account or security be risked whilst doing so.

Quote:

Originally Posted by Pickletron

This project looks amazing! I could play around in Sandboxes all day!
Good luck with it, can't wait to play it x.x

EDIT: I always wondered what it would be like working in GW, spawning Shiro and Glint in the same room then making them duke it out.
Would you be able to do this in GWLP? I'm drooling just thinking about epic boss battles!!

Very much possible, I've been flying around presearing as Kuuanavang for a while now

Quote:

Originally Posted by DarkNecrid

I love this project, and kind of had an idea for a PvP server where everyone played with bosses like Shiro etc ;P

Could you possibly explain how hard making a skill would be?

Once the skill scripting system is finished it should be relatively easy, now remember I said relatively - it won't be point and click, there will be real scripting involved. But it's something anyone who puts the time in could learn.

Quote:

Originally Posted by Targren

I'm confused...

If everything in the GWLP is going to be home-grown "sandbox" style content and not official GW content, then what's the need for the authentication that allows you to only play content you've purchased, when you can't play official content on the server anyway?

I don't get it...

Whilst the majority of GWLP content, in terms of quests etc will be unique. I'm sure there will be some crossover from the live servers in terms of skills. Skills are actually not part of the Guild Wars client, they're server side - meaning you have to pay to access them. We do not want to allow you to access those skills for free, so authorization will be required to do so.

Wrath Of Dragons · Oct 12, 2007, 04:15 PM // 16:15

Quote:

Originally Posted by Targren

I'm confused...

If everything in the GWLP is going to be home-grown "sandbox" style content and not official GW content, then what's the need for the authentication that allows you to only play content you've purchased, when you can't play official content on the server anyway?

I don't get it...

Because, in a sence you are still playing "guildwars". because the content that GWLP uses is provided to anyone by ANet for free (you can download the entire game without owning an account, all the account does is grant you access to the game). GWLP would allow anyone to play it, including people who never bought guildwars, so they have the authentication process running in the background to make sure you are able to log onto guild wars, and thus have already paid arenanet. If they didnt do this, then GWLP would be undermining guildwars, and anet would shut it down pretty quickly, im sure.

Ajaala, if this post is wrong, tell me and its gone

Akaraxle · Oct 12, 2007, 05:29 PM // 17:29

Quote:

Originally Posted by Ajaala

That is not our aim, more information in the original post and subsequent posts.

I can read, was just further remarking the point for those that are still going on about it.

Gusnana1412 · Oct 12, 2007, 11:23 PM // 23:23

Quote:

Originally Posted by Ajaala

You do not understand our authorization system. It does not record your username and password at any time, all it does is wait for you to log into a real account and identify the packets that say "Ok! Ajaala owns chapter 2!" and so on, it then sends that information "Ajaala owns chapter 2" to the GWLP server, which lets you use chapter 2 content. At no point does it use your username, password, or any other personal information. The only info it looks at is what you own. There is no security risk and Anet does not need to modify their login system.

I don't explicitly saying you will saved the informations (but you might, because it is closed sources and there are no full support from ANet), but what I said, intercept data between user and GW by a third party without full authorization from both party is not legal. (even if it's use for a good purpose, without both authorization it still not legal)

My point: GWLP Authorization System should be evaluated by ANet developer or have full support from them~

Note: This project playing with someone else account/investment in this case Guild Wars account (directly). By any means if something happen, GWLP will not able to prevent damage that might happen not or asking support from GW (because there is no full support from ANet/NCSoft for third party)

Ajaala · Oct 20, 2007, 03:21 PM // 15:21

Hello again, as promised I'm here to keep you updated with goings on in the GWLP camp, as well as post some fun media for you all. As many of you know, last week Gaile from Arenanet posted in one of my threads to let us know that as long as GWLP didn't allow players who do not own Guild Wars to use a GWLP server, Anet sees no immediate reason why the project can not continue.

Which is why this week I'm introducing to you the

Auth System

The auth system works as follows: (warning, technical explanation!)

Quote:

Originally Posted by Scary Technical Mumbo Jumbo

1. Players start a GWLP utility that runs in the background.
2. Players log into their official Guild Wars account.
3. The program reads two specific bytes from the account data packets
4. It hashes these two bytes when plugged into a special pattern
5. Then makes another hash from Guild Wars and everything is encrypted
6. The program then sends this information to the GWLP server
7. When you log into GWLP, the server reads the auth data from the database, verifying hashes and timestamps.
8. If everything is OK it sends those two bytes in the proper packet.
9. Authorization expires after 10 hours.

What this essentially means is, the GWLP utility finds out what content you're entitled to use on the Guild Wars servers, and restricts access to anything but that content on the GWLP servers. At no point does the GWLP program read, record, or use your username and password, or any other information that could damage the security of your Guild Wars account. Whilst we're aware the community is very vigilant regarding key loggers and account stealing programs, this is a long way from release anyway, and in the future we'll try to get people YOU trust to verify that these programs are harmless before we release them for use.

The following is an image I took upon joining the GWLP server and forgetting to run the auth program:

Miscellaneous Updates

Despite the auth system being the main focus of today's update, there has been some progress in other areas.

The ability to access maps no longer available on live has been worked on, allowing us to explore test maps and previously unseen terrain.

The new Ascalon recruits gather to honor the first rank 12 GWLP player!

This one exceeds explanation

As always, any concerns, doubts, queries or questions, PM me or ask in the thread and I'll respond as soon as possible.
I hope you enjoy the continued progress.

Ajaala

Visit Us!
http://gwlp.mgcorp.org

Neo Nugget · Oct 20, 2007, 03:41 PM // 15:41

Yeah, i'm curious to what this is actually. Looks very interesting.

zwei2stein · Oct 20, 2007, 04:05 PM // 16:05

I dont really like that authorization expiring thou ... my hopes for gwlp are to play it even after oficial servers went dead

Chthon · Oct 20, 2007, 06:54 PM // 18:54

Quote:

1. Players start a GWLP utility that runs in the background.
2. Players log into their official Guild Wars account.
3. The program reads two specific bytes from the account data packets

What's to stop me ("me" being the Troublesome User, not me personally) from spoofing these packets in the first place? Can't I just direct the client to another phony server (or just a loopback to my own machine) that will send the "right" packets in pretty much the same way that you direct the client to the GWLP server?

Quote:

4. It hashes these two bytes when plugged into a special pattern
5. Then makes another hash from Guild Wars

I'm not following you on this second hash. What exactly is the input that you're hashing? GW.exe? GW.dat? Some more game data? What?

Depending on what it is, I'm worried that I could spoof it too, using input trivial enough to allow me to reverse the second hash, which would, in turn, allow me to reverse the first hash via brute force. (It's only 2 bytes after all.)

Quote:

and everything is encrypted

If this is meant to be a security measure against me, then you really shouldn't be giving me the encryption key, even if it's obscured by being in a post-compile binary. Encryption is fundamentally a security measure against third parties. Trying to use encryption to keep one of the parties privy to the message in the dark inherently relies on the dubious assumption that that party lacks the ability to crack open the black box that you've given them.

Apropos of encryption, what kind of encryption are you using? I might suggest using an asymmetric key here. That way, once I determine the encryption key, although I can encrypt spoofed auth data, at least I will remain unable to decrypt and read legit auth data. (Not that there's a whole slew of different messages the auth data can contain.)

Quote:

6. The program then sends this information to the GWLP server
7. When you log into GWLP, the server reads the auth data from the database, verifying hashes and timestamps.

Timestamp? Where'd that come from? Both in the sense that "you now mention verifying it, but you never mentioned creating it," and in the sense of
"what data source are you using to tell the time?" Unless the official GW server is kind enough to tell you the time, I can just spoof it on you.

More importantly, what's going to stop me from duplicating my auth data for all my friends? Unless I missed something, none of the information that you describe the GWLP server as collecting uniquely identifies either my PC or my GW account. (Moreover, if it did uniquely identify my GW account, I'd have a real big problem with it.) I am getting the impression that two users with identical GW installations and identical GW access rights who authenticated at the same time would generate identical auth data. That's not hard to fake. (I might add (parenthetically) that the history of uniquely-identified-PC security is one of near-utter failure, so going in that direction is probably not a solution.)

As I said before (and was apparently ignored), I don't believe there exists a way to accurately authenticate users so long as you do not look at the sort of GW-account-specific data that is properly forbidden for you and users have no incentive to refrain from helping their friends log in as pirates. (I might add that GW's official auth system only works (in principle, if not in current implementation,) because there's a huge incentive not to give your auth data (aka login+passord) to your friends.)

(All of that said, considering the HUGE hole in GW's authentication that you guys (supposedly) just found, I think a-net complaining about your authentication being inadequate would be "the pot calling the kettle black.")

l3j · Oct 20, 2007, 09:07 PM // 21:07

Quote:

Originally Posted by Chthon

What's to stop me ("me" being the Troublesome User, not me personally) from spoofing these packets in the first place?

Scroll up.

Quote:

Originally Posted by chthon

Can't I just direct the client to another phony server (or just a loopback to my own machine) that will send the "right" packets in pretty much the same way that you direct the client to the GWLP server?

Your phony server would have to have access to the GWLP server's database to affect authorization in any way. Also, if you tricked the client into being authorized client-side, you still would be rejected by the server when trying to play.

Quote:

Originally Posted by Chthon

I'm not following you on this second hash. What exactly is the input that you're hashing? GW.exe? GW.dat? Some more game data? What?

The computer information used for reconnecting is used.

Quote:

Originally Posted by Chthon

Depending on what it is, I'm worried that I could spoof it too, using input trivial enough to allow me to reverse the second hash, which would, in turn, allow me to reverse the first hash via brute force. (It's only 2 bytes after all.)

No, the first hash is not of only two bytes.

Quote:

Originally Posted by Chthon

If this is meant to be a security measure against me, then you really shouldn't be giving me the encryption key, even if it's obscured by being in a post-compile binary. Encryption is fundamentally a security measure against third parties. Trying to use encryption to keep one of the parties privy to the message in the dark inherently relies on the dubious assumption that that party lacks the ability to crack open the black box that you've given them.

Quote:

Originally Posted by Chthon

Apropos of encryption, what kind of encryption are you using? I might suggest using an asymmetric key here. That way, once I determine the encryption key, although I can encrypt spoofed auth data, at least I will remain unable to decrypt and read legit auth data. (Not that there's a whole slew of different messages the auth data can contain.)

The same encryption instruction Guild Wars uses.

Quote:

Originally Posted by Chthon

Timestamp? Where'd that come from? Both in the sense that "you now mention verifying it, but you never mentioned creating it," and in the sense of
"what data source are you using to tell the time?" Unless the official GW server is kind enough to tell you the time, I can just spoof it on you.

When the server receives the authorization data the time stamp is created. You can spoof it regardless, a time server can be emulated.

Quote:

Originally Posted by Chthon

As I said before (and was apparently ignored), I don't believe there exists a way to accurately authenticate users so long as you do not look at the sort of GW-account-specific data that is properly forbidden for you and users have no incentive to refrain from helping their friends log in as pirates. (I might add that GW's official auth system only works (in principle, if not in current implementation,) because there's a huge incentive not to give your auth data (aka login+passord) to your friends.)

Neither party (authorization client and server) can be trusted. So there isn't a secure solution to this problem. The authorization client and server can both be cracked. All that can be done is hinder the amount of time cracking the software takes.

Quote:

Originally Posted by Chthon

(All of that said, considering the HUGE hole in GW's authentication that you guys (supposedly) just found, I think a-net complaining about your authentication being inadequate would be "the pot calling the kettle black.")

Pablo24 found the exploit just over the course of a day. The only relation the exploit has to the GWLP is that he is a staff member. Whether you believe me or not doesn't change the validity of my statements.

holababe · Oct 20, 2007, 11:21 PM // 23:21

Looks good.
Given that I could examine the authentication program, I would be willing to test it.
Thanks for updating anyway.

Chthon · Oct 21, 2007, 01:52 AM // 01:52

Quote:

Originally Posted by l3j

Your phony server would have to have access to the GWLP server's database to affect authorization in any way. Also, if you tricked the client into being authorized client-side, you still would be rejected by the server when trying to play.

Let's try this again. I run your little utility and launch GW. The utility sniffs incoming packets from the official GW server, right? And it's looking for a couple of bytes that denote my ownership rights, right? Then it gift wraps them and ships them off to the GWLP server, right? Now, let's go back a step. How does your utility know that those packets it's sniffing are really coming from the official GW server?

I'm imagining something like this: I create Server A. Sever A speaks the encryption the the GW client is expecting, shakes hands, accepts any user/password combo, shoots back "you are authorized to play all 4 games," maybe mimics the real login server a bit longer, then discos. Now, I redirect my GW client to Server A in place of the official GW server. So, now, when I run your auth util, then run the GW client, the util sniffs "you are authorized to play all 4 games," gift wraps that, and ships it off to your server, allowing me to play all 4 games for the next 10 hours.

I do not see anything in Ajaala's description to prevent this sort of chicanery.

Quote:

The computer information used for reconnecting is used.

That's not terribly forthcoming, but at least it's more than Ajaala explained. I think I've stated my reservations about the effectiveness of using a hardware profile to identify a user before, so let's skip that for now. How do you deal with the legitimate user with variable hardware? If I authenticated desktop, logging in from my laptop (or my desktop after some hardware upgrades) is going to fail, isn't it? Unless, you let me re-authenticate from the laptop. But that would defeat the whole purpose of using a hardware profile to uniquely identify me; if all one has to do is precede gameplay with an auth session, there could be any number of "me's" doing so.

Quote:

No, the first hash is not of only two bytes.

Ajaala said "It hashes these two bytes." I took him/her (?) at her word there. Apparently, "plugged into a special pattern" is vague-speak for "we take the two bytes, pad it with garbage, then hash." I'll admit that makes me feel a little better about your method here.

Quote:

The same encryption instruction Guild Wars uses.

I'm sorry. I incorrectly assumed this was an effort to keep the end user from learning how to spoof their own auth data. I completely forgot that you also have to protect against third party attacks. In that case, go-go hardcoded encryption. Query: Is there a reason that you must use GW's encryption scheme for a communication between the auth util and your server? I'd assume you could use any scheme you wanted between your own program and your own server, so you could use something stronger.

Quote:

When the server receives the authorization data the time stamp is created.

OK, so the timestamping is purely serverside to keep track of the 10-hour limit?

Quote:

You can spoof it regardless, a time server can be emulated.

Good point.

If you can see this, why don't you see the possibility of an emulated "real" GW server spoofing the input your auth util is sniffing?

Quote:

Neither party (authorization client and server) can be trusted. So there isn't a secure solution to this problem. The authorization client and server can both be cracked. All that can be done is hinder the amount of time cracking the software takes.

That is entirely my point. I'm glad you see it that way too. The important question that follows is then: Is this level of insecure-but-annoying enough to satisfy a-net so that they won't shut the project down once it reaches a playable level of functionality and people start trying to play beyond their access rights? This goes back to my original comment on the topic (in the other thread): While I'm excited about the GWLP project, I'm not going to dedicate time to it if it's ultimately doomed; get an official statement that a-net is satisfied with your authentication system and then I'll be willing to help. If GW were my game, I would not be satisfied with your auth system, and I would cite the impossibility of a secure solution as my reason for shutting you down. Fortunately for you, it's not.

Perhaps a-net is less demanding than I. Go press for that official statement and see.

Quote:

Pablo24 found the exploit just over the course of a day. The only relation the exploit has to the GWLP is that he is a staff member. Whether you believe me or not doesn't change the validity of my statements.

I was not suggesting in any way that GWLP has anything to do with this exploit. I accept that it's a mere coincidence. My point was that a-net's own auth system is apparently so poor that it would be hypocritical of them to ask much more from yours. It was a compliment about the comparative quality of your auth system; you should have taken it, said thanks, and run with it

Whirlwind · Oct 21, 2007, 02:08 AM // 02:08

While a great idea, I"m betting anet is going to put the wraps on this now~

holababe · Oct 21, 2007, 03:00 AM // 03:00

Chthon: It's likely that the GWLP development team is deliberately not being forthcoming with information in order to limit the ability of people to spoof the auth. packets.

Just a question - is there anything in the packets from the ANet servers that identifies them as unique?

l3j · Oct 21, 2007, 11:53 AM // 11:53

Quote:

Originally Posted by Chthon

Let's try this again. I run your little utility and launch GW. The utility sniffs incoming packets from the official GW server, right? And it's looking for a couple of bytes that denote my ownership rights, right? Then it gift wraps them and ships them off to the GWLP server, right? Now, let's go back a step. How does your utility know that those packets it's sniffing are really coming from the official GW server?

I'm imagining something like this: I create Server A. Sever A speaks the encryption the the GW client is expecting, shakes hands, accepts any user/password combo, shoots back "you are authorized to play all 4 games," maybe mimics the real login server a bit longer, then discos. Now, I redirect my GW client to Server A in place of the official GW server. So, now, when I run your auth util, then run the GW client, the util sniffs "you are authorized to play all 4 games," gift wraps that, and ships it off to your server, allowing me to play all 4 games for the next 10 hours.

I do not see anything in Ajaala's description to prevent this sort of chicanery.

There is nothing that I know of that would stop this from being a problem.

Quote:

Originally Posted by Chthon

That's not terribly forthcoming, but at least it's more than Ajaala explained. I think I've stated my reservations about the effectiveness of using a hardware profile to identify a user before, so let's skip that for now. How do you deal with the legitimate user with variable hardware? If I authenticated desktop, logging in from my laptop (or my desktop after some hardware upgrades) is going to fail, isn't it? Unless, you let me re-authenticate from the laptop. But that would defeat the whole purpose of using a hardware profile to uniquely identify me; if all one has to do is precede gameplay with an auth session, there could be any number of "me's" doing so.

The system prevents authorizing different accounts using one computer. However, if those computers are imitating the real computer those accounts will be authorized. The consequences of sharing your real account still apply although it is certain people will share with their friends. But the reason for sharing would be to play together which can be prevented only if the accounts were authorized on the same computer. In addition, banned and suspended accounts cannot be used to authorize.

In short, it can't be prevented while allowing free roam for the user. Even then, not in absolution.

Quote:

Originally Posted by Chthon

I'm sorry. I incorrectly assumed this was an effort to keep the end user from learning how to spoof their own auth data. I completely forgot that you also have to protect against third party attacks. In that case, go-go hardcoded encryption. Query: Is there a reason that you must use GW's encryption scheme for a communication between the auth util and your server? I'd assume you could use any scheme you wanted between your own program and your own server, so you could use something stronger.

Simplicity. Perhaps if trouble occurs I can always use something better.

Quote:

Originally Posted by Chthon

OK, so the timestamping is purely serverside to keep track of the 10-hour limit?

Yes, it is.

Quote:

Originally Posted by Chthon

If you can see this, why don't you see the possibility of an emulated "real" GW server spoofing the input your auth util is sniffing?

I've been able to see that problem from the start.

Quote:

Originally Posted by Chthon

That is entirely my point. I'm glad you see it that way too. The important question that follows is then: Is this level of insecure-but-annoying enough to satisfy a-net so that they won't shut the project down once it reaches a playable level of functionality and people start trying to play beyond their access rights? This goes back to my original comment on the topic (in the other thread): While I'm excited about the GWLP project, I'm not going to dedicate time to it if it's ultimately doomed; get an official statement that a-net is satisfied with your authentication system and then I'll be willing to help. If GW were my game, I would not be satisfied with your auth system, and I would cite the impossibility of a secure solution as my reason for shutting you down. Fortunately for you, it's not.

Perhaps a-net is less demanding than I. Go press for that official statement and see.

An official statement stating that the project is permissible is beyond hope. The most that can be hoped for is ArenaNet stating they will refrain from legal action unless blah, blah, and blah.

Quote:

Originally Posted by holababe

Just a question - is there anything in the packets from the ANet servers that identifies them as unique?

If you mean as in for sure from ArenaNet...no, there isn't. The only thing that uniquely identifies the packets as being from ArenaNet are the opcodes. Which can be emulated.